Transaction cards (credit or debit) are well known in the art. Generally, transaction cards have gained wide acceptance because of their convenience for the purchaser as a replacement for cash and for the certainty of payment for the merchant as opposed to personal checks. The typical transaction card includes the owner's name and account information (issuing bank, account number, expiration date, etc.). This data may be embossed on the card and/or stored in memory on the card. Since this critical data is not hidden, there exists a risk of fraud. In a traditional transaction, the purchaser presents the transaction card to the merchant who in turn receives an authorization approving the transaction from the purchaser's bank that issued the transaction card. However, it is the merchant's responsibility to ensure that the person presenting the transaction card is the actual owner of the transaction card. Thus, the merchant typically will request picture identification from the purchaser and/or compare the purchaser's signature to a signature on the transaction card.
Although this system works generally well, there are significant disadvantages. First, there is a reliance on the diligence of the owner and the merchant to defect fraud. Lost or stolen transaction cards may be used to complete a transaction if the owner is not quick to inform the issuing bank and the merchant is not diligent in requesting identification and comparing signatures. Lost or stolen transaction cards go unreported because the owner may not discover the problem until several days have passed. Merchants are not always diligent because of the high turn over rate and low skill sets of the employees that are processing the transactions at the check out counter. Second, there is an increasing trend to use transaction cards in some transactions (via the internet, phone, facsimile or mail) that do not occur in person (face to face). Therefore, the merchant has no ability to request picture identification or compare signatures. This increases the likelihood that a lost or stolen transaction card could be used fraudulently. Third, unscrupulous people may get access to the transaction card data (name, bank, account number, expiration date, etc.) even if the owner is still in possession of the transaction card. This occurs because the transaction card data is often openly available. As examples, the transaction card data is printed on receipts and bank statements that may be viewed by unintended people. As another example, unscrupulous people may monitor the electronic transactions or overhear telephone transactions to obtain the data. Still another example is computer hackers breaking into the database of the issuing bank and stealing whole volumes of transaction card data. Yet still another example is unauthorized use of the transaction card data by the merchant's point of sale staff that may use the transaction card data for their own purchases or sell the information to others.
One attempt at a security measure to address this issue is described in U.S. Pat. No. 6,052,675 which is directed to preauthorizing a credit card for a particular transaction that is contemplated to occur in the future. In anticipation of a transaction, the credit card owner provides the bank with the owner's account number and requested network data or vendor information. Then, during the transaction approval process, the vendor transmits the account number and requested network data to the bank for verification. If the network data requested of the user and the network data received from the vendor match, then the transaction is approved. Otherwise, the transaction is not approved.
Although this security measure adds a degree of increased security, it suffers from disadvantages and drawbacks. First, merely because the owner inputs network data in advance of the transaction does not reduce all aspects of fraud. For example, if the bank requests that the owner input the location (city/town, state) of the vendor, then a lost or stolen credit card may still be successfully used by an unscrupulous person in that location. The bank would automatically disapprove only uses outside of the specified location. As another example, if the bank requests that the owner input the date and/or time of the anticipated transaction, then the unscrupulous person may still be able to use the credit card on that date. Only uses outside of the specified data and/or time would be disapproved. Similarly, if the bank requests that the owner input the vendor name, then the unscrupulous person may be fortunate enough to use the lost of stolen credit card with the named vendor, especially where the named vendor is a large retailer or department store. Therefore, the opportunity for fraud still exists. Second, having the bank request the network data from the owner may not provide the owner with the type of control the owner desires. On one hand, the bank may dictate too much specificity by requesting input of a varied type and detailed amount of network data. This may be too restrictive to meet the needs of the owners. For example, where the owner desires broader privileges, the input of detailed network data may be time consuming when multiple transactions are contemplated. On the other hand, the bank may not designate sufficient type and amount of network data. In this instance, the owner may not be able to appropriately limit the use of the card in the manner desired by the owner.
Therefore, there is a need for a method and system that provides increased protection against fraud while providing the transaction card owner with flexibility in defining what transactions are authorized. In this way, the banks incur fewer losses due to fraud and the owners gain increased control over the use of the transaction card.